1. Field of the Invention
The present invention relates generally to a communications infrastructure and, more particularly, to a system and method for providing a service that enables and manages communications between distributed applications and legacy systems in distributed computing environment.
2. Background of the Invention
The mainframe-based information technology (IT) environment is still a common architecture in many large organizations. One of the most popular operating systems for mainframes is IBM's OS/390. OS/390 consists of several subsystems, including IMS (Information Management System) and CICS (Customer Information Control System).
Mainframe based applications can be integrated into distributed computing environment using a CORBA-based system. CORBA is OMG's (Object Management Group's) open, vendor-independent specification for an architecture and infrastructure that computer applications use to work together over networks. CORBA is designed to provide interoperability between applications that may be written in different languages and may run on different platforms. CORBA defines an implementation independent object model, which is built with a programming language, such as C++ or Java. CORBA provides object services that are domain-independent interfaces that are used by many distributed object programs.
CORBA defines an ORB (Object Request Broker) that handles the transport of information between applications. The ORB functions as a communications infrastructure, transparently relaying object requests across distributed heterogeneous computing environments. ORB simplifies distributed programming by decoupling the client from the details of the method invocations. Interoperability is accomplished through well-defined object interface specifications, which allow client applications to connect to the ORB, specified in OMG IDL (Interface Definition Language). OMG IDL defines the types of objects according to the operations that may be performed on them and the parameters to those operations.
FIG. 1 shows the basic CORBA ORB architecture. Client 100 is the entity that wishes to perform an operation on an object. The object, which is known as a “servant” and implemented by a server, is an entity that consists of an identity, an interface and an implementation. Object implementation 102 is a code and data that actually implements the object. Object implementation 102 provides the semantics of the object, usually by defining data for the object instance and code for the object's method. The objects export object references with interfaces specified by the OMG IDL for use by clients. The object reference contains an identification of the object implementation so that the object adapter can pass the client's request to the correct object in the server. The CORBA architecture is implemented in a conventional programming language, such as C, C++, Java, or Smalltalk.
To use CORBA, OMG IDL specification is written and compiled to generate client stubs and server skeletons in the languages in which client and server are written. The stubs and skeletons serve as proxies for clients and servers, respectively. The stubs and skeletons are then included in the client's program and the server's program, respectively. Thereafter, client 100 initiates a request to an operation on object implementation 102 through IDL stub 106. The request is an event carrying information that includes an operation, an object reference of the service provider, and actual parameter. IDL stub 106 represents the mapping between the language of implementation of client 100 and ORB 104. IDL skeleton 110 represents the mapping between the language of implementation of object implementation 102 and ORB 104. ORB 104 locates the appropriate implementation code, transmits parameters and transfers control to object implementation 102 through IDL skeleton 110. In performing the request, the object implementation may obtain some services from ORB 104 through object adapter 112. When the request is complete, control and output values are returned to client 100.
Orbix, which is a CORBA compliant ORB from IONA Technologies, Inc., has become a popular CORBA based system. Orbix uses a connection-oriented network design where each client process establishes a socket connection to each server process. Socket is a TCP/IP (Transmission Control Protocol/Internet Protocol) application programming interface that allows connection between two TCP/IP programs. For example, each of one hundred clients on system X communicating with one hundred servers on system Y would use 10,000 (100×100) sockets. The number of sockets of a system is limited. For any OS/390 process, for example, there is a practical limit of 2,000 simultaneous socket connections.
FIG. 2 is a block diagram showing a mainframe-based system integrated into distributed computing environment. As an example, system 200 is a legacy system running on OS/390 and integrated into distributed computing environment using Orbix. Subsystem 208 of system 200, as an example, is an IMS. An OS/390 mainframe can include multiple IMS control regions. An IMS adapter, such as Orbix IMS adapter, is loaded on each of the control regions. The IMS adapter allows the client to remotely call and communicate with IMS applications. As shown in FIG. 2, IMS adapter 206 is loaded on control region 222. Access to transaction 220 is realized via IMS adapter 206. IMS adapter 206 includes interfaces for communications. IMSraw interface 210 is one of such interfaces. IMSraw interface 210 is a generic interface offering an operation “run transaction” for invoking legacy transactions.
To execute transaction 220 in IMS 208, client 202 obtains an object reference of IMS adapter 206 from name service 204. Client 202 can use name service 204 to obtain the object reference. Client 202 then sends a request to execute transaction 220 to IMS adapter 206 through IMSraw interface 210. Client 202 establishes a socket connection to IMS adapter 206. IMS adapter 206 receives the request and forwards the request to control region 222. The request is processed (i.e., the transaction is executed). IMS adapter 206 sends a response to client 202. Clients 230, 232 and 234 perform the same process described above to execute transaction 220. Each client establishes a socket connection to IMS adapter 206.